Each magic5 system contains one or more customers, with each customer having one or more associated locations/sites/projects.
Customers are fundamental to the system in that each form must be completed “for” a particular location (and hence customer). Jobs are also specified for a location (and hence customer). The various job and report pages within the system usually allow the filtering of jobs and completed forms via customer and, optionally, location.
Note that a location has to be “beneath” a customer (ie. it can’t exist without a customer).
In some systems, especially where the “real” customer is a member of the public, it might not make sense for each individual to be set up as a magic5 “customer”. Hence it may make sense to have a magic5 “Customer” of “General customer” (for example) and the “real” customer details would be recorded as part of the form.
A customer will have associated information: often simply an address, but maybe a Sage code or similar.
In order for a customer to appear in various parts of the system it must have at least one location defined, even if this is a “head office” type location.
A location (or site or project) is in some ways even more fundamental than the customer. Forms are always recorded against locations, and jobs are always allocated to them. Aside from a location address, there tends to be a much wider set of information associated with a location than with a customer. For instance, pricing information, drawings and plans, and supplementary items such as ward lists. Contacts can be associated either with the customer as a whole (“customer-wide contacts”) or they can be associated with a location (“location contacts”). Contacts have a name and standard contact details such as e-mail address; phone number; mobile number.
Such permanent contacts are worthwhile adding to magic5 for a number of reasons:
Contact information can easily be selected when creating a job in the office, without having to re-enter data each time
Contact information can be made available on the device, with simple “tap” options to phone, send text messages and send e-mails
Automated actions can be created to e-mail completed forms to contacts – these require a location or customer to have contacts setup on the system with e-mail addresses
Note that a contact and a “customer” user account are not the same thing. Setting somebody up as a contact on the system may ensure that they receive e-mails of completed work but it won’t allow them to login to the system. A user account with a role of “customer” will allow login to the system but the user won’t appear as a contact for the customer concerned when creating or viewing a job or form.
In cases where contacts typically do need user accounts it’s possible to (optionally) automatically generate user accounts when contacts are created.
